home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / UNSPLIT / text0550.txt < prev    next >
Encoding:
Text File  |  1997-02-06  |  1.5 KB  |  36 lines
  1.  
  2. > I have one (two) small question. How fast is it on the Afterburner040?
  3.  
  4. E1M1 (standard benchmark on startup):
  5.  
  6. 15 FPS -> 40Mhz 68040 / 50Mhz DSP / compat_level #2
  7. 9 FPS -> 32Mhz 68040 / 32Mhz DSP / compat_level #99
  8.  
  9. I can only get away with compat_level #2 because my DSP is so speedy. This way,
  10. the bus never catches up with it and the CPU barely needs to handshake at all.
  11.  
  12. > Will you do any modifications to speed it up further on the AB040?
  13.  
  14. Not much I can do that doesn't involve a big rewrite. :)
  15.  
  16. > Johan talked about drawing the screen in Fast RAM and then copy it
  17. > to 'video RAM' (ST-RAM). Or am I totatly wrong here? 
  18.  
  19. I tried that (used 'move16' to transfer 16-byte DPHRASE chunks on each instruction)
  20. but it's just a fraction slower than normal. It is much faster than normal when
  21. there are transparent textures on the screen though - makes a big difference there.
  22. Might be a worthwhile option for nasty WADs. :)
  23.  
  24. The Falcon's 16-bit bus is so crap that the screencopy takes just as long as drawing
  25. all of the pixels one by one in vertical columns. I imagine the fact that I pipelined
  26. the drawing loops to death has contributed to this invariable screen access time. 
  27. Badly pipelined code would have gained more from a FastRAM buffer because the loops
  28. would 'choke' less on the delays caused by plotting to quick ram.
  29.  
  30. If the Falcon had a 32-bit bus then the difference would have been marked, but as
  31. it stands there's not much hope for a fastram screenbuffer making a hell of an
  32. improvement in most cases.
  33.  
  34. Doug.
  35.  
  36.